Database system

ABSTRACT

A database system that accommodates any type of phenomenon or thing, with a simple table structure and an extremely small-scale program. Category identification information of the content to be registered, item names that represent an attribute and/or a function included in the category, and attributes of data representing the substantial contents of these items (item data attributes) are registered in each data cell of a data property table ( 21 ) in units of rows, and category identification information, title names, and substantial contents associated with each item are registered in data cells of a main data table ( 22 ) in units of rows. The item names of the table ( 21 ) and the substantial contents of the table ( 22 ) correspond by means of cell numbers, and when a database management system ( 10 ) performs data input, storage, searching, and output, the various methods are generated with row-direction data of the table ( 21 ) as a message.

TECHNICAL FIELD

The present invention relates to a database system into whichinformation is stored as data made up of category names, title names,and the substantial contents, and more particularly to a system intowhich information belonging to all categories is stored in an extremelysimple table structure and managed by small-scale software, which can beapplied as an online database enabling storage and viewing from aclient.

BACKGROUND ART

With widespread use being made of information devices such as personalcomputers and a fleshing out of online services via networks such as theInternet, the last few years have seen a dramatic increase in the numberand variety of databases available.

In the past, database models have included network, hierarchal,relational, and object-oriented types, with the relational database(hereinafter referred to as the RDB) being the most widely used atpresent, and the object-oriented database (hereinafter referred to asthe OODB), formed by introducing object orientation into a databasesystem, being used as the main method for software development, thedevelopment and implementation of which are being actively pursued.

The implementation of object relational databases (hereinafter referredto as the ORDB), formed by introducing objection orientation into theRDB, is also being actively pursued.

The RDB, as the term is used herein, refers to representation of data bytables made up of rows and columns and the relationships between eachtable, the table representation of data facilitating an understanding ofthe data model structure, making the design thereof relatively simple.

In the RDB, normal forms are used to reduce data redundancy (that is,reduce the duplication of data) and to simplify lookup and updating, byusing a table structure free from such waste. In the past, severalstandard normal forms have been proposed (the Codd first to third normalform, the Boyce/Codd extended third normal form, and the fourth normalform by R. Fagin and so on), and it is possible to obtain the mostefficient table structure based on these standards.

Additionally, SQL (Structured Query Language) has become the standardaccess language, this having the advantage of enabling extraction ofdata without coding a procedure via an engine that interprets SQLstatements.

On the other hand, in the OODB, objects, which encompass data and theassociated procedures (methods), are the subject of management, with theprogram being coded for the exchange of instructional commands and data(messages) between objects.

Objects of one and the same type are grouped into a class (abstractlydefined in terms of functions and attributes common to the objects),with an upper-order class method being inherited by a lower-order class.

In the OODB, there is a large number of data structure types, and byencapsulating the data and methods as noted above it is possible toachieve an operating environment in which the data is treated directlyin the same easy-to-understand manner as would real objects, thisspecial feature being that it is now possible to store not onlycharacters and values, but also to store images and sounds.Object-oriented languages include such languages as C++, Smalltalk, andJava.

In the RDB, although the table structure is designed in accordance withconforming to the above-noted standard of normal forms, these standardsare merely a system of logic, with actual tasks being performedsequentially while graphing a large number of individual file groups,thereby rendering the design of a table structure extremely complex andtroublesome, and requiring the expenditure of a great amount of time andlabor.

In a database handling a wide range of information, there is anextremely large number of table groups, and it is necessary to manageeach table group individually. Additionally, in the operating process,if there is a change in an item or the like of one table, it is oftennecessary to make a change to related tables and programs, the resultingediting task also, as noted-above, being extremely difficult.

In the case of the OODB, because data and methods with regard toindividual stored information are encapsulated in objects, in the case,for example, of a change made to items or data in a company employeedatabase, it is necessary to open the object of each employee and makesuccessive changes, and when this is associated with a method, it isnecessary to do an in-depth study of whether an inheriting class wouldbe influenced, the result usually being that it is necessary to performmore complex and difficult re-editing of the program than would havebeen involved with the RDB.

Stated differently, although the OODB is directed at achieving a userinterface for efficient operation, and provides efficient programming atthe point at which a method is inherited, it requires a high level ofexperience with regard to storage and management of individual objects,and programming of messages, and when a large amount of data isinvolved, the amount of work required for maintenance of the OODBbecomes much greater than the work required by the RDB.

With regard to the ORDB, which is basically a hybrid of the RDB and theOODB, because its configuration is more complex, it is accompanied bythe same problems as the RDB or the OODB.

Accordingly, it is an object of the present invention to provide ahighly functional database, which has only an extremely simplified tablestructure and handles the storage of any category of information,enabling efficient execution of the essential database functions ofentry, storage, retrieval, and output of data using small-scalesoftware, and further enabling the implementation of a database systemproviding extreme flexibility and simplicity in making changes to anitem associated with stored information, solving the above-describedproblems associated with the RDB and the OODB, and providing economicalimplementation and operation.

A database system according to the present invention enables freeinteractive storage of information from a client via a communicationline such as the Internet, without the intervention of a programmer, andfurther provides the same level of user interface convenience as wouldbe provided by the OODB.

DISCLOSURE OF INVENTION

The first invention is a database system, while managing category names,which are abstract contents of registered information (phenomena orthings), and the hierarchy thereof by a data dictionary file, registerscategory name, individual title name, and substantial contents of eachpiece of information being registered, wherein the above-noted systemcomprising a first table and a second table, which are formed by datacells, and in the above-noted first table, category identificationinformation given by the above-noted data dictionary file is stored in adata cell of a specific column, and names of items which represent anattribute and/or a function associated with the category and attributesof data representing the substantial contents associated with theabove-noted items (hereinafter referred to as item data attributes) arestored in other cells, each belonging to a row in which the above-notedcategory identification information is stored, and in the above-notedsecond table, category identification information and a title name arestored in each cell of two specific columns, the substantial contentsassociated with each item name being stored in other data cells, eachbelonging to a row in which category identification information andtitle names are stored, in the same sequence with regard to item namesas the row-direction sequence of data cells into which are stored itemnames and item data attributes in the above-noted first table, and eachmethod for input, storage, searching, and output of data associated withregistered information being generated based on data stored in theabove-noted first table.

In this first invention, data of registered information belonging to allcategories is managed using two tables having a simple structure.

In the first table, category identification information and “item namesand item data attributes” associated with that category are stored intoeach data cell in units of rows, and in the second table categoryidentification information, title names, and substantial contentsassociated with each of the item names of the information are storedinto each data cell in units of rows, both of the stored data beingassociated by the category identification information, and the “itemnames and item data attributes” and “substantial contents associatedwith the each item name” being associated by the item names, in the rowdirection sequence of each data cell.

The first table is a virtualization of the “substantial contentsassociated with each item name” of the second table, in the data formatof “item names and item data attributes,” and based on this virtualnature, it is possible to store and manage data of registeredinformation belonging to all categories in a single second table.

Additionally, based on the properties of the “item data attributes,” itis possible to generate each method for the execution of eachfunction-(i.e. input, storage, searching, and output) which isindispensable for the database system by merely providing a singleprocess control program to the each function.

That is, in contrast to a database system of the past, in which theconfiguration was one having a large number of tables related in acomplex manner, with separate read/write programs corresponding to eachcontrol program for executing each of the above-noted functions, orvarious joint programs which take into consideration the inter-tablerelationships, thereby requiring a very large program, with the presentinvention it is possible to implement the same type of database systemwith an extremely simplified table structure and a small program only.

Seen in terms of operation, the above-noted first invention enables theconfiguration of the following second invention.

The second invention, comprising: a first storage means into which isstored a first registration screen onto which are disposed an inputfield for a category name, which is an abstract concept of handledinformation, an input field for each item name representing an attributeand/or a function associated with the above-noted category, and an inputfield for defining item data attributes for each item associated withthe above-noted item names; a first display means for reading out anddisplaying a first registration screen of the above-noted first storagemeans; a first table formed by data cells; a first registration means,which uses data cells of a specific column of the above-noted firsttable as a storage area for category identification information given bythe above-noted data dictionary file and assigns each data cell of theother column as a storage area for item names and item data attributes,and which, based on input into the above-noted each input field of theabove-noted first registration screen, registers the above-notedcategory identification information, item names, and item dataattributes in units of rows; a second display means for displaying asecond registration screen, which generates a display method based onrow-direction data associated with the above-noted category name of theabove-noted first table, and on which is disposed an input field for atitle name associated with the above-noted registered information, adisplay field for display of each item name, and an input field forsubstantial contents associated with each item name; a second tableformed by data cells; a second registration means, which uses each datacell of two specific columns of the above-noted second table as storageareas for category identification information and title names andassigns each data cell of other columns as a storage area forsubstantial contents associated with the above-noted item names, andwhich, based on input into each input field in the above-noted secondregistration screen, stores category identification information, titlename, and substantial contents associated with each item name in unitsof rows, this storage being performed so that row-direction sequence ofthe above-noted each data cell into which the above-noted substantialcontents associated with each item name is stored is the same withregard to item names as a row-direction sequence of each data cell inthe above-noted first table, into which are stored item names and itemdata attributes; a data output means, which, in a case in which aninquiry is made with various conditions, based on data registered in theabove-noted first table associated from the above-noted data dictionaryfile, generates an access method for the above-noted second table and anoutput method for registered data obtained by that access method, thesemethods causing output of registered data in response to the above-notedinquiry.

In the second invention, the first storage means and the first displaymeans, by displaying the first registration screen, which corresponds toa guidance screen, cause input of the category name, the item names, anditem data attributes for each of the item names.

The first registration means, based on the input from the firstregistration screen, causes storage of input data in units of rows intoeach data cell of the first table, and virtualizes the “substantialcontents associated with each item name” of the second table, in thedata format of “item names and item data attributes.”

The second display means displays a second registration screen, whichcorresponds to a guidance screen for the purpose of inputting the titlename, item names, and substantial contents for each item name ofinformation to be registered. In this case, the second display means,based on the table configured with data that virtualizes the firsttable, can generate a display method for the second registration screenfrom the row-direction data associated with that category identificationinformation.

Data registered in the first table, therefore, serves the role ofdefining the display conditions for the second registration screen bythe second display means.

The second registration means, based on input to the second registrationscreen, causes storage into each data cell of the second table of theabove-noted category identification information and the input data, inunits of rows.

The correspondence between the first table registered data and thesecond table registered data is set as described with regard to thefirst invention.

Therefore, the data registered in the first table serves the role ofdefining for the second registration means the conditions for storage ofsubstantial contents for each individual item name associated withregistered information.

The data output means receives an inquiry directed at registeredinformation in the database system.

The inquiry conditions include various conditions, such as searchingusing a category name or title name as a key, searching usingsubstantial contents associated with an item name as a key, andsearching with further narrowing of the scope of substantial contents,i.e., registered data of the first table with association to a datadictionary file responsive to the searching conditions being determined,this registered data being used to generate an access method for thesecond table, and in the case in which the recorded data of interest isto be output, an output method is generated based on the data registeredin the first table.

Data registered in the first table, therefore, serves the role ofdefining searching conditions and outputting conditions for the dataoutput means.

As described above, the second invention performs registration of datainto the first table and into the second table, while providing thefirst registration screen and the second registration screen as guidancescreens, enabling management (entry, storage, searching, and output) ofdata using these two tables, this being made possible by the above-notedvirtual nature of the first table. This virtual nature functionseffectively as well in the generation of the second registration screen.

Stated differently, in contrast to a database of the past, in which inthe case in which it was necessary to register a new category, aprogrammer performed design of a complex table structure and generationof a very large program, according to the present invention, a categoryname, item names, and item data attributes for each item name are inputbeforehand, following guidance, after which a simple procedure offollowing guidance in registering a title name, item names, andsubstantial contents for each item name is performed, with subsequentindividual instructions with regard to entry, storage, searching andoutput, being handled as if a program were being automatically developedand driven in real time, thereby achieving what could be called a“virtual object-oriented” database system.

In the above-noted first and the second inventions, by providing a datatype as a defined item of data attributes, it is possible to execute theabove-noted functions of entry, storage, searching and output, and it isfurther desirable to provide data size as an additional attribute.

In the case in which the data size is not defined, there are many casesin which there is a difference between the amounts of data in thesubstantial contents for each item name of data to be registered intothe second table, and if the data cell capacity is set to the maximumvalue thereof, a large amount of memory capacity is wasted.

Given the above, if the data size is defined as noted above, and it ismade possible to vary the setting of the required capacity for each datacell in the second table, it is possible to solve this problem.

For one and the same category, it can be known empirically that theamount of data for the substantial contents of each item name is almostthe same.

In addition to the above-noted data type and data size, if it is madepossible to specify units and a range, it is possible to properlyrepresent any attribute or function associated with each item of eachphenomenon or event existing in the natural world, thereby not onlysimplifying the registration process, but also broadening the scope ofcontent that can be registered.

Next, if a selection menu is provided for the above-noted data types forcharacter, value, date, image, and audio, it is possible tocomprehensively cover the representations of substantial contents foreach item name.

In addition to these basic data types, if a selection menu is providedfor independent data types for data obtained by linking to anotherapplication and/or to another system, it is possible to freely captureand register various data existing outside the system, enabling use as adata warehouse and configuration of a distributed database.

In the second invention, although the capacity of the data cells of thesecond table, as noted above, can be made variably settable based ondata attributes defined by the first table, in the case in which thetype of the substantial contents associated with an item name is inputas image or audio and so on, the amount of data is much greater than thecase of character or date data types.

On the other hand, because of the system characteristics, there could bea limitation to the capacity of a data cell in the second table, andfrom the standpoint of data management as well, it is not desirable tohave a great difference in capacity between individual data cells of atable.

Given the above, in such cases, if the substantial contents data isstored in a separately provided large-capacity second storage means, andonly the addresses of the data stored in the second storage means arestored in the data cells of the second table, it is possible to solvethe above-noted problem.

In the second invention, if the first storage means stores the firstregistration screen provided with input fields in display sequencecorresponding to the input fields for input of each item name, and thefirst registration means adds each input display sequence to the itemdata attributes corresponding to each item name, storing this in eachdata cell of the first table, and the data output means generates anoutput method, on which the display sequence for the substantialcontents associated with each item name is set, based on the displaysequence associated with the above-noted input, it is possible toarbitrarily set the display sequence for substantial contents associatedwith the item names, so that when displaying the information resultingfrom a search, it is not only possible to perform uniform registeredinformation output, but also to perform output with a display screenlayout that is suitable to the category.

The third invention relates to a configuration in which the secondinvention is applied as an online database system.

In this invention, in response to a connection request sent via anetwork from a client, a circuit connection is made with the client, andin response to a client-side registration request, the above-noted firstregistration screen generated by the above-noted first display means isprovided to the client-side, and based on transmission of input data tothe above-noted first registration screen by the client-side, the inputdata is registered into the above-noted first table, and based on theabove-noted registered data associated with the above-noted categoryidentification information of the above-noted first table, theabove-noted second registration screen generated by the above-notedsecond display means is provided to the client-side, and based ontransmission of input data to the above-noted second registration screenby the client-side, the input data is registered into the above-notedsecond table, and, based on an inquiry from a client-side, variousinquiry screens prepared beforehand are provided to the client-side, andin response to inquiry condition input to the screen, the above-noteddata output means provide the registered data of the above-noted secondtable to the client-side.

In the above-noted case, in contrast to an online database of the past,which only had viewing and searching functions via a network, thisinvention makes it possible to perform database registration ofinformation of any category extremely simply, while receiving onlineguidance.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a system configuration diagram showing an online databasesystem (DBS) to which the present invention has been applied.

FIG. 2 is a drawing showing an example of the hierarchal structure ofcategories in the configuration below an area.

FIG. 3 is a drawing showing an example of the configuration of acategory level management table (CLMT).

FIG. 4 is a flowchart showing the setting registration procedure fordata properties (DP).

FIG. 5 is a drawing showing a DP setting screen initially provided,based on DP setting screen data.

FIG. 6 is a drawing showing a DP setting screen input for a categoryname “Dog.”

FIG. 7 is a drawing showing a DP setting screen (first page) input for acategory name “General Telephone Apparatus.”

FIG. 8 is a drawing showing a DP setting screen (second page) for thecategory name “General Telephone Apparatus.”

FIG. 9(A) is a drawing showing a pull-down menu of data types for aninput field in a DP setting screen, FIG. 9(B) is a drawing showing apull-down menu of the maximum character length for an input field, FIG.9(C) is a drawing showing a pull-down menu for the range associated witha input, and FIG. 9 (D) is shows a pull-down menu displayed when thedate data type is selected.

FIG. 10 is a drawing showing a schematic representation of theconfiguration of a data property table (DPT).

FIG. 11 is a flowchart showing the registration procedure for main data.

FIG. 12 is a drawing showing the registration, update, and deletionscreen for data having the category name “Dog.”

FIG. 13 is a drawing showing the registration, update, and deletionscreen (first page) for data having the category name “General TelephoneApparatus.”

FIG. 14 is a drawing showing the registration, update, and deletionscreen (second page) for data having the category name “GeneralTelephone Apparatus.”

FIG. 15 is a drawing showing a schematic representation of an example ofthe configuration of a main data table (MDT).

FIG. 16 is a drawing showing a screen with a list display of upper-ordercategories.

FIG. 17 is a drawing showing a screen display of a tree representationassociated with the upper-order category of Pet Animals.

FIG. 18 is a flowchart showing the search procedure with respect to arequest for a list display of the category “Dog.”

FIG. 19 is a drawing showing a screen with a list of data of thecategory “Dog.”

FIG. 20 is a flowchart showing the search procedure with respect to arequest for a viewing in which the title name “Amber” was specified.

FIG. 21 is a drawing showing the retrieved content screen (searchresults screen) from a search on the category name “Dog” and the titlename “Amber.”

FIG. 22 is a drawing showing the retrieved content screen (searchresults screen) from a search on the category name “CommunicationTerminal” and the title name “T-3360 Telephone Apparatus.”

FIG. 23 is a flowchart showing the search procedure with respect to aconditional search request for the category name “Dog.”

FIG. 24 is a drawing showing a conditions setting screen for a datasearch for the category name “Dog.”

FIG. 25 is a drawing showing a list display screen obtained from aconditional search.

BEST MODE FOR CARRYING OUT THE INVENTION

An optimum embodiment of a database system (hereinafter referred to asthe DBS) according to the present invention is described below, withreference made to accompanying drawings.

First, FIG. 1 shows a system configuration diagram of an online DBS towhich the present invention is applied.

In this drawing, the reference numeral 1 denotes the DBS, 2 is theInternet, and 3-1 to n are clients (terminals such as personalcomputers) connected to the Internet 2 via modems and web browsers.

In this case, the DBS 1, similar to the case of a conventional DBS, hasa database management system (hereinafter referred to as the DBMS) 10connected to the Internet 2 via a communication control unit 11 such asa router and a web server 12, the DBMS 10 being connected to a hard diskdrive (hereinafter referred to as the HDD) 13 for data storage and afile server 14, and to a personal computer 15 provided for management.

The DBS 1 has an HDD 13, into which are stored various screen data 18for system function menus and the like, a category level managementtable (hereinafter referred to as the CLMT) 10 corresponding to the datadictionary file of a conventional database system, data property(hereinafter referred to as DP) setting screen data 20, a DP table(hereinafter referred to as the DPT) 21, and a main data table(hereinafter referred to as the MDT) 22, and enable data registrationinto the HDD 13, as well as viewing and searching of this data onlinefrom the clients 3-1 to n.

A particular feature of this system is that the processing of registereddata is handling by the two tables, the DPT 21 and the MDT 22, thoughthe system deals with data of registered information (phenomenaor-things) belonging to every category, and that the management andmaintenance of registered data is performed by the DBMS 10, which isextremely simplified software, this representing a unique conceptentirely different from a DBS of the past.

To demonstrate the efficiency of these particular features, a conceptualdescription will first be provided below with regard to the handling ofcategories in the DBS 1. Additionally, data registration (DP settingregistration and main data registration), data viewing (searching andoutput) and modification (updating and deleting), and category itemaddition and deletion will be described in sequence, with referencesbeing made to flowcharts and various display screens.

1. Handling of Categories

In the DBS 1, as shown in FIG. 2, information that is handled isclassified into the areas of “▪ Electronic Bulletin Board”, “▪Electronic Catalog”, “▪ Company Information”, “▪ Member Management”, and“▪ Information”.

In the above, the “▪ Electronic Bulletin Board” is a bulletin board areainto which a client 3 can write various information for publicdisclosure, the “▪ Electronic Catalog” is an area for public disclosureof product information and the like of the client 3 in catalog format,“▪ Company Information” is an area for public disclosure of generalinformation and stock information about the company, “▪ MemberManagement” is an area for management of information with regard tomembers using the system, and “▪ Information” is an area fordissemination of notices from the system administrator, these areasbeing only examples, it being possible to provide various areas asnecessary.

As data registration into the DBS 1 proceeds, various hierarchalcategory levels are formed below each of the above-noted areas, thiscondition being shown by examples given in FIG. 2.

In this drawing, the upper-order categories, marked by □, are providedat the discretion of the administrator of the DBS 1, or in response to arequest from a client 3 or in response to the condition of registrationof data and the like, and categories marked with ⋄ are categories thatcan be established by the administrator of the DBS 1, but which aremainly selected and set freely by a client 3 at the time of dataregistration, and at this category level, the DP are also being set andregistered into the DPT 21.

Although in FIG. 2 only category levels down to the levels marked by ⋄are shown, it is possible to establish category levels below these asnecessary.

On the other hand, in the DBS 1, the above-noted hierarchal structure ismanaged by the CLMT 19 having a data cell structure as shown in FIG. 3.

In this case, the CATG_KJ (category name) column regards each area ofFIG. 2 as a category level, each lower-order category name thereunderbeing stored on a separate line. The CATG_NO (category number) columnstores numbers which correspond to each of the above-noted categorynames as category identification numbers on the same line, a new numberbeing sequentially assigned to categories

each time a category name is added.

The ROOT_CATG_NO (root category number) column is assigned numbers forthe uppermost-order categories, such as 1/2/3/4/5 for the areas ▪Electronic Bulletin Board/▪ Electronic Catalog/▪ Company Information/▪Member Management/▪ Information, which indicate to which area categorynames there below belong. The PARENT_CATG_NO (parent category number)column indicates the category number of the category name of higherorder. For each of the above-noted areas, since there is no higher ordercategory, the PARENT_CATG_NO is 0.

By referencing the CLMT 19, therefore it is possible to verify thehierarchal position of areas and each category name.

2. Data Registration Procedure

In the DBS 1, main data registration into the MDT 22 is done, with thepremise being that the DP are set and registered into the DPT 21.

Although whether or not the client 3 performs this registrationprocedure continuously is arbitrary, because the data registrationprocessing is performed independently in this system, each registrationprocedure will be described separately herein.

(1) DP Setting/Registration Procedure

This registration procedure is shown in the flowchart of FIG. 4.

First, when the client 3 makes connection to the DBS 1 via the Internet2, the DBMS 10 reads the member verification screen data (18) from theHDD 13, and sends this to the client 3, which inputs the ID and passwordinto the prescribed locations thereof and sends this to the DBS 1 (S1 toS3).

At the DBS 1, when the ID and password are verified as being proper forthe member, the system is opened up to the client 3, and function menuscreen data (18) is read out from the HDD 13 and sent to the client 3(S4 and S5).

The function menu screen provided to the client 3 is a screen for thepurpose of selecting various functions, such as “DP Setting” and “MainData Registration” of the DBS 1.

If “DP Setting” menu is selected from this screen, an area list screen(with guides to lower-order levels) is provided as the initial screen,from which the client 3 performs instruction operations, in response towhich a selection screen for upper-order categories belonging tolower-order levels of the areas is provided (S5).

There screens are formatted as a list display or tree display, either ofthese being generated by the DBMS 10, based on management data of theCLMT 19.

If the client 3 selects “DP Setting” at the upper-order category, at theDBS 1 the DBMS 10 reads out DP setting screen data 20 from the HDD 13,and sends this to the client 3 (S6 and S7).

At this point, the screen provided and displayed to the client 3 basedon the DP setting screen data 20 has the configuration shown in FIG. 5.

As shown in the drawing, this screen has a field for inputting thecategory name, which is an abstract concept of the registeredinformation, input fields for each item name representing an attributeand/or a function of that category, input fields for the data type forrepresentation of the substantial contents associated with each itemname, and an additional Although it is not shown in this drawing, theregion surrounded by a broken line is used to display input guidance.

Other fields provided are the display sequence as already input initialvalues, which can be overwritten, fields for the input style and displaystyle, into which are input the style codes given later at the DBS 1,and a data registration field, which is used to indicate whether or notit is desired to register main data registration is to be performedbelow the category name.

When the above-noted DP setting screen (FIG. 5) is displayed at theclient 3, input is made of the desired category name for registration(category belonging to the upper-order category selected at step S5),each item name (including a change in the display sequence, ifnecessary), and the data type for display of the substantial contentsfor each item name (S8).

In this case, in making the input of the data type, buttons provided tothe right of each input field are clicked, at which point a pull-downmenu such as shown in FIG. 9(A) is displayed, from which selection canbe made.

When each item name and data type are input and the “Next” button at thebottom is clicked, input fields for the maximum character lengths,units, ranges, search specification (whether or not the data is to besearched on), and a list display (whether or not to make a list display)are individually displayed on the display area of the above-noted inputguidance.

For example, if “Pet Animals” is selected as the upper-order category,and the category name is “Dog” as shown in FIG. 6, the assumption ismade that input is made of the item names Breed, Age, Weight, Height,Male/female, tricks, Favorite Food, Pedigree, Owner, and Photography,when data types ofcharacter/value/value/value/character/character/character/character/character/imageare set so as to represent the substantial contents of these item names,an input field enabling display of a pull-down menu such as shown inFIG. 9(B) is displayed in the maximum character length field forcharacter type items. For value type items, a length of no greater than64 single-byte characters is assumed, and, although the maximumcharacter length field is blanked, in its place input fields for unitsand range specification are displayed. In the case of an image item,because there is no need for a maximum character length, units, or arange specification definition, all these are blank. For the rangespecification, a pull-down menu such as shown in FIG. 9(C) is provided.

The prescribed input is made from the client side 3 into the inputfields for the maximum character length, units, range specification,searching specification, and list display, and if the character lengthis specified as unlimited, a input field is displayed by the size of theestimated number of rows and columns, and the input is done to thefield.

The screen shown in FIG. 6 shows the condition in which the input to theDP Setting screen for the above-noted category name “Dog” has beencompleted.

On the other hand, the two pages of screens shown in FIG. 7 and FIG. 8show the conditions in which input has been completed in the DP Settingscreens when “Electrical Communication Terminal” is selected as theupper-order category and “General Telephone Apparatus” is selected asthe category name, in which, although there are more item names thanwhen “Dogs” is selected as the category name, input is made by followingthe same type of procedure.

In this case, the item name is selected with the data type of theapproval year, month, and day being the date, an input field of apull-down menu such as shown in FIG. 9(D) being displayed in the columnfor the maximum character length, based on this selection, and an inputfield of a pull-down menu such as shown in FIG. 9(C) being displayed inthe range specification column, prescribed input being made into thesefields.

In the DP Setting screens (FIG. 6 to FIG. 8) for the various above-notedcategory names, Plug-in/audio/E-mail/URLLink/download/password/Intersystem Link is not selected within the datatype indicated in FIG. 9(A).

“Plugin” is provided for the case of movie data, “Audio” is provided forthe case of audio data, “E-mail” is provided for E-mail data, “URL Link”is provided for data on a web page on the Internet 2, “Download” isprovided for downloading of data from the Internet 2 or a local areanetwork (LAN), “Password” is provided for a password used when viewingthe substantial registered contents, and “Intersystem Link” is providedfor capturing of data from another system or application, and whilethese are similar to the foregoing described forms of screens, whensubstantial main data is to be registered later, a dedicated wizard orspecial notation format is required (with the format **** for thepassword).

When the DP Setting screen input is completed as described above fromthe client 3, the contents update button is clicked to send the input tothe DBS 1 (S8).

On the other hand, at the DBMS 10, when the setting data is receivedfrom the client 3, the category name thereof is registered in theCATG_KJ of the CLMT 19, a serial number is applied as the CATG_NO, andappropriate numbers are given to and stored into the ROOT_CATG_NO andthe PARENT_CATG_NO (S10).

For example, if as shown in the above-noted example (DP settings of FIG.6), “Dog” is selected as the category name, and this is the firstregistration operation for this category name, as shown in FIG. 3 “Dogs”is registered as a CATG_KJ, “16” is stored as the serial number intoCATG_NO, “1” is stored into the ROOT_CATG_NO since this corresponds toregistration into the “▪ Electronic Bulletin Board” area, and, becausethe upper-order category is “Pet Animals,” “11 a 5”, which correspondsto the CATG_NO thereof, it is stored in the PARENT_CATG_NO.

As shown in the DP settings of FIG. 7 and FIG. 8, in the case of thefirst registration into the category name “General Telephone Apparatus,”“18” is stored as the serial number into CATG_NO, and, because thiscorresponds to registration in the area “▪ Electronic Catalog,” “2” isstored into the ROOT_CATG_NO, and, because the upper-order category is“Electrical Communication Terminal,” “11”, which corresponds to thatCATG_NO, is stored into the PARENT_CATG_NO.

In the case in which the same category name already exists in theCATG_KJ of the CLMT 19, if there is a request for DP settingregistration, when this is done a CATG_NO is given, at which point theregistered category name is assigned and registered as “Dogs 1” so as todistinguish this from the previous “Dogs” (refer to CATG_NO 21 in FIG.3).

Next, the DBMS 10 causes the received DP setting data to be stored andregistered into the DPT 21 (S12).

The method of registration into the DPT 21 is shown in FIG. 10.

First, the DPT 21 is a table formed by data cells, the DBMS 10 assigningthe first column for storage of the PARENT_CATG_NO, assigning the secondcolumn for storage of the CATG_NO, and assigning the third andsubsequent columns for storage of the item names, display sequence, datatype, data size, units, range specification, searching specification,and list display of the above-noted DP setting data.

In this embodiment, the numbers starting at (1) and incrementing upwardare assigned to the data cells from the third column in the DPT 21.

In the description to follow, the phrase “item data attributes and thelike” will be used to refer collectively to the “display sequence, datatype, data size, units, range specification, searching specification,and list display,” and the term “item data attributes” will be used torefer to only the “data type, data size, units, and range specification”thereof.

The DBMS 10, based on the above-noted assignment method, stores “itemname and item data attributes and the like” of the received DP settingdata into each data cell in units of rows along with the numbers of thePARENT_CATG_NO and CATG_NO previously stored into the CLMT 19 (S12).

As a result of the above, if the received setting data was a categoryname of “Dogs” and a category name of “General Telephone Apparatus,” theregistration is actually made in the form shown in FIG. 10, thisregistration format being the same for all other categories as well, sothat the DP setting data for one category is always registered into oneline of the DPT 21.

The data registered into each line of the DPT 21 is thus associated bythe PARENT_CATG_NO and the CATG_NO with the area, upper-order category,and category name registered in the CATG_KJ of the CLMT 19.

There are cases in which a category name for which registration isrequested already exists in the CLMT 19, and the DP setting data thereofis registered in the DPT 21, so that the request is made forregistration of one and the same category name.

In such cases, separate individual storage is performed at the DBS 1,regardless of whether or not the “item names and item data attributesand the like” are the same, but because the category names are the same,storage is done in CATG_KJ of the CLMT 19 after adding an identifiersuch as “1” R “2” to the category names. For example, the existence inthe CLMT 19 of FIG. 3 of both CATG_KJ: “Dog” with a CATG_NO of “16” andCATG_KJ: “Dog1” with a CATG_NO of “21,” and a similar example forCATG_KJ: “General Books” is the result of the above-noted processing.

In these cases, if the “item names and item data attributes and thelike” are all the same or have a common part, this information is storedin the added information field of the CLMT 19 (column after CATG_KJ inFIG. 3), and provided for use in a later list display or searchprocedure.

It is also possible, in contrast to the above-noted processing performedin this DBS 1, to permit only one registration in a single categoryname.

(2) Main Data Registration Procedure

The main data registration procedure is shown in the flowchart of FIG.11.

The data registered into the DPT 21 is not the substantial dataregistered, but a virtualization thereof in the form of the “categoryname,” the “item name of associated attributes and/or functions,” and“attributes possessed by data representing the substantial contentsassociated with the item name.”

However, because this is virtualized data, this function is extremelyrational in registering substantial contents in associated with maindata in this registration procedure.

First, in the registration of main data as well, when the client 3 makesconnection to the DBS 1 via the Internet 2, a function menu screen (18)is provided, by following the same type of procedure as in theabove-noted case of “DP Setting,” except that in this case the client 3selects the “Main Data Registration” from this menu (S21 to S25).

Then, in this case as well, the DBS 1 provides an area list displayscreen as an initial screen, based on the above-noted function menuselection, whereupon the client 3 performs an instruction operation fromthis screen, so as to transition from area, to upper-order categories,to categories, in sequence, moving down in the hierarchy of levels oflist or tree displays, until ultimately the client 3 is presented with acategory selection screen (S25).

That is, the client 3 successively makes specifications of an area andan upper-order category associated with the current information to bemade, selecting the desired category from registered categories,following the above-noted DP setting registration procedure.

Upon receiving the category selection data and the main dataregistration request at the DBS1, the DBMS 10 generates registrationscreen data for the substantial contents associated with the selectedcategory, and sends this to the client 3 (S26 and S27).

If, for example, the category name is “Dog,” this registration screen isas shown in FIG. 12, and if the category name is “General TelephoneApparatus,” the registration screen is as shown in FIG. 13 and FIG. 14,with input field of the sent registration screen except for the codenumber left blank.

Specifically, the registration screen, as shown in the drawings, isformed by a title indicating that the screen is an input screen forregistered data of a particular category name, a code number displayfield, an input field for a title name of the registered information,and input fields for item names and the substantial contents associatedwith each item.

In this case, the sent registration screen data is obtained by the DBMS10 searching for the CLMT 19 (FIG. 3) CATG_KJ using the selectedcategory name as a key, searching for the DPT 21 (FIG. 10) CATG_NO usingthe CATG_NO corresponding to the category name as a key, and generatinga display method based on an “item name and item data attributes” storedin each data cell in the row direction and having one and the samenumber in the DPT 21.

As is clear by referring to FIG. 6, FIG. 10, and FIG. 12 in the case ofthe category name “Dog” and by referring to FIG. 7, FIG. 8, FIG. 10,FIG. 13, and FIG. 14 in the case of the category name “General TelephoneApparatus,” the input fields for substantial contents associated witheach item of the registration screen are formed by sizes, units, andinput methods and the like corresponding to the item data attributes ofthe DPT 21, thereby providing an easy-to-understand screen for use whenthe client 3 makes input of substantial contents to be registered.

The DBMS 10 performs preparation for the purpose of storing substantialcontents of registered information received later into the MDT 22 (S28).

That is, in order to secure in advance, the capacity of data cells inthe row-direction to be registered with substantial contents which willbe received later, the capacities of the data cells that correspond tothe MDT 22 are successively set, based on the data type and maximumcharacter length of each item associated with the said category name ofthe DPT 21.

And at the client 3, the desired substantial contents associated withtitle name and each item name, as shown in FIG. 12 (for the case of thecategory name “Dog”), or FIG. 13 and FIG. 14 (for the case of thecategory name “General Telephone Apparatus”), is input via the inputfields of the above-noted registration screen, and the “Register” buttonat the bottom is clicked to send the input data to the DBS 1 (S29).

If the item name is Photo and the data type is image, however, an imageregistration button appears to the side of the input field of theregistration screen and, by clicking this button, a wizard that givesinstructions for the capture of image data is launched, the image databeing captured as registered data by following the instructions thereof.

The same is true in the cases in which the data type is Plugin, Audio,Download, or Intersystem Link, capture of data in each case beingexecuted based on a wizard for each data type.

On the other hand, at the DBS 1, which has received the above-notedregistered data, the DBMS 10 stores and registers the CATG_NO, titlename, code number, and substantial contents of each item associated withthe category name into each data cell of the MDT 22 in units of rows(S30 and S31).

The method of data registration into the MDT 22 is shown in FIG. 15.

First, the MDT 22 is a table formed by data cells, the first column ofwhich is assigned to the row number, the second column of which isassigned for storage of CATG_NO, the third column of which is assignedfor storage of a title name, the fourth column of which is assigned forstorage of the code number, and the fifth and subsequent columns ofwhich are assigned for storage of substantial contents associated witheach item name. In this embodiment, the numbers starting at (1) andincrementing upward are assigned to the data cells from the fifthcolumn.

The DBMS 10 successively stores substantial contents associated witheach item name into data cells of the MDT 22 having the same number asthe data cell numbers of the DPT 21.

Specifically, in the above-noted case of registered data in which thecategory name is “Dog” and the title name is “Amber,” as shown on lineNo. 148 of FIG. 15, the category number of “Dog,” which is “16,” isstored beforehand in the data cells of the CATG_NO column, “Amber” isstored in the data cell of the title name column, and the substantialcontents associated with Breed, Age, Weight, Height, and so forth arestored in data cells of ascending data cell numbers, and each data beingstored in the same manner on row No. 287 for the case of the categoryname “General Telephone Apparatus” and the title name “T-3360 TelephoneApparatus.”

The capacity of each data cell is set beforehand at step S28 of theabove-noted procedure to a capacity into which each of the substantialcontents can be stored.

For example, however, in line No. 287 associated with the title name“T-3360 Telephone Apparatus” of FIG. 15, the data of the “IMAGE FILE No.43” is stored into the data cell number (4).

This occurs because, as shown in the DP setting screen (FIG. 7), theconfiguration of the DPT 21 (FIG. 10), and the registration screen (FIG.13), the data cell number (4) of the above-noted line No. 287 isbasically for storage of a photograph with the data type of image, andwhen the “Image Registration” button is clicked in the registrationscreen at the client 3, the image registration wizard that is launchedis followed in storing the image data, the DBMS 10 causing this imagefile to be stored on the HDD 14 a of the file server 14, and the addresson the file server 14, being “IMAGE FILE No. 43,” is stored into theabove-noted data cell of the MDT 22.

That is, in the DBS 1 of this embodiment, to avoid a great unbalance inthe amount of data stored in data cells of the MDT 22, in the cases inwhich the data type is Image, Plug-in, Sound, or Download, these dataare stored as files at the file server 14, with only this file numberregistered into the data cell of the MDT 22.

By doing this, the DBS 1 of this embodiment, as shown in FIG. 15, causesstorage into the MDT 22 of the registered information associated withvarious categories other than “Dog” and “General Telephone Apparatus,”the substantial contents stored in the each data cell of the MDT 22being associated with item data attributes stored in data cells of theDPT 21 having the same data cell numbers.

As shown in FIG. 15, the DBS 1 of this embodiment is characterized bythe fact that it stores each substantial contents to be registered forall categories in a single table, the MDT 22, and by the fact that eachof the substantial contents of the MDT 22 is virtualized in the form of“item names and item data attributes and the like” by the DPT 21.

The DBS 1 of this embodiment, by virtue of the above-notedcharacteristics, features not only an extremely simplified tablestructure, but also an extremely simple program for performing variousprocedures such as data viewing (searching and output), datamodification (updating and deletion), and changing items associated witha category, which will be described later.

3. Data Viewing (Searching and Output) Procedure

First, in the DBS 1 of this embodiment, the appropriate selection ismade at the client 3 at the area list display and various other screensprovided from the DBS 1, resulting in receipt of an upper-order categorylist such as shown in FIG. 16. However, for the viewing of this data,which is by its very nature generally is publicly disclosed, knowledgeof whether or not the client 3 is a member is not required, and thetransmission of the membership verification screen or the inputprocedure for the ID and password is not required.

Display of the upper-order category list, for each category name in theCLMT 19, based on the upper-order category names or information areasgiven by the administrator of the DBS 1, shows whether lower-orderclasses exist, a field for selecting whether or not lower-order listdata is to be viewed, and general descriptions of the registered dataincluded in each of the upper-order categories.

For example, “View List Data” is selected for an upper-order categoryname “Pet Animals” on this screen, a list display screen in tree formatsuch as shown in FIG. 17 is provided.

These display screens are formed by a prescribed display method, by theDBMS 10 referencing the CLMT 19 and the DPT 21.

The following description starts from the search procedure in the casein which “View a list of Dogs data” is selected at the tree displayscreen of FIG. 17.

The search procedure is shown in the flowchart of FIG. 18.

When the above-noted selection is made, the DBMS 10 launches a data listdisplay program for a specified category (S41 and S42), and searches theCATG_KJ of the CLMT 19 to verify the CATG_NO “16” corresponding to “Dog”(S43).

Next, the DBMS 10 searches the second column (CATG_NO column) of the DPT21 (FIG. 10) and reads out the setting data in the row directioncorresponding to the above-noted number “16,” immediately generating adisplay method as a message of this, and generating layout data of thedata list of the category “Dog” (S44).

Next, the DBMS 10 searches the second column (CATG_NO column) of the MDT22 (FIG. 15), reads out the registered data in row directioncorresponding to the above-noted number “16,” and writes the readoutdata into various prescribed locations of the layout data justgenerated, so as to generate the display screen data (S45).

In this case, as is made clear by mutually referencing the row directionsetting data, which in the CATG_NO “16” in the DPT 21 of FIG. 10 and theregistered data in the row directions at which the CATG_NO is “16” inthe MDT 22 of FIG. 15, there is a correspondence set up by the CATG_NO“16” with regard to the category name, and a correspondence set upbetween each of the “item names and item data attributes and the like”in the DPT 21 and the substantial contents associated with each itemname at the MDT 22, by numbers of the data cells, thereby greatlysimplifying the program used to generate the above-noted display screendata.

Then the generated display screen data is sent to the client 3, at whichit is displayed as data list of the category “Dog” such as shown in FIG.19 (S46).

In the list display of FIG. 19, for the item examples “Tricks,”“Favorite Food,” and “Photo,” the “New Window” link is provided becausethe large amount of data for these items in the DPT 21 would make itimpossible to establish a sufficient display area in the case of thelist display.

While the foregoing description is limited to the category name of“Dog,” as noted in the discussion of DP Setting/Registration Procedure,when a request is made for registration of an existing category name, anidentifier such as 1 or 2 is appended to the latter category namesbefore storage into the CATG_KJ of the CLMT 19, and when all the “itemnames and item data attributes and the like” are the same or when thereare common parts, that information is stored in an additionalinformation field. Naturally, main data is also stored with regard to acategory name having such an identifier appended thereto.

In this DBS 1, in the case in which a data list display has been made ofthe category “Dog,” in principle the categories “Dog” and “Dog 1,” whichhave different category names, will be displayed on separate listdisplays, but when the such added information as noted above is stored,it is also possible to include part or all of the registered data for“Dog 1” within the data list for the category “Dog” by using thatinformation.

Next, in the data list of the above-noted category “Dog,” if anindividual underlined title name or each New Window part is clicked, itis possible to provide and display the corresponding information.

In particular, if a request is made to view by clicking a separate titlename part, a search is made for the registered items for that titlename, and a response screen can be displayed that includes allsubstantial contents.

Given the above, the procedure up to the point of obtaining the responsescreen for the case in which a request is made to view the title name“Amber” from the data list for the category “Dog” is described below,with reference to the flowchart of FIG. 20.

First, when the title name “Amber” is clicked from the screen shown inFIG. 19, the DBMS 10 launches the content displaying program forsearched data (S51 and S52).

Then, based on this program, the DBMS 10, similar to the case describedabove, searches the CATG_KJ of the CLMT 19 (FIG. 3) to verifies CATG_NO“16” corresponding to “Dog” (S53).

And, the DBMS 10 searches the CATG_NO of the DPT 21 (FIG. 10), androw-direction setting data corresponding to CATG_NO “16” is read out,immediately generating a display method as a message of this, generatinglayout data for the response screen associated with the category “Dog”(S54).

In this case, the layout data is generated based on each item dataattributes and the like stored in the data cells (1) to (11) associatedwith the category name “Dog” of the DPT 21 (FIG. 10), the displaysequence of the substantial contents associated with each item name andthe method of display thereof are given as data by each of the item dataattributes and the like, therefore, the above-noted program onlyautomatically designs the layout by using those data.

Next, the DBMS 10 searches the CATG_NO column and the title name columnof the MDT 22 (FIG. 15), reads out row-direction data for a row in whichthe CAT_NO is “16” with the title name “Amber,” and writes this intoeach prescribed location of the layout screen data just generated,thereby generating the response screen data (S55).

The DBMS 10 sends this response screen data to the client 3, at which itis presented as a response screen such as shown in FIG. 21, enablingverification of the substantial contents of the “dog named Amber” thatwas requested (S56).

The above-noted layout design program adaptively generates a layoutmethod, taking the item data attributes and the like of each item nameas messages, and is not a program that is designed and preparedbeforehand for individual category names.

With regard also to the writing of the substantial contents associatedwith each item name into the layout data, similar to the case of causinga display of the above-noted data list, because each of the “item namesand item data attributes and the like” at the DPT 21 (FIG. 10) and thesubstantial contents associated with each of the item names of the MDT22 (FIG. 15) correspond by means of data cell numbers, it is possible toexecute this with a very simple program description.

Therefore, while a program for generating a response screen based on aviewing request is given as a single general-purpose program notspecific to any category name, it automatically generates an adaptivedisplay method with respect to each different category name.

Although not shown in the drawings, if there is a viewing request thatspecifies the title name “T-3360 Telephone Apparatus” as in the datalist for the category name “General Telephone Apparatus,” a proceduresimilar to the one noted above is used to adaptively generate a displaymethod for the category name “General Telephone Apparatus,” a responsescreen such as shown in FIG. 22 being provided to the client 3.

Next, a search (hereinafter referred to as a conditional search) inwhich a category name and another condition are specified, of the typeoften used in general DBS, is described below.

With the category name “Dog” specified, this conditional search processis described below, with reference being made to the flowchart of FIG.23.

First, although not shown in the drawing, in this embodiment there is ascreen that permits specification of a conditional search as an option,and, when a conditional search is specified at the client 3 from thisscreen, the DBMS 10 launches a program for this purpose (S61 and S62).

Then, based on this program, the DBMS 10, similar to the above-notedcase, searches the CATG_KJ column of the CLMT 19 (FIG. 3), and verifiesthe CATG_NO “16” corresponding to “Dog” (S63).

A display method using the row-direction setting data associated withthe CATG_NO “16” of the DPT 21 (FIG. 10) as a message generatescondition setting screen data such as shown in FIG. 24, this being sentto the client 3 (S64).

Upon receiving the above-noted screen, the client 3 can specify variousconditions in the input fields of the screen of FIG. 24, and the exampleshown is that in which the “Age” conditions of at least 2 years old andno greater than 4 years old and the “Weight” conditions of at least 15kg and no greater than 35 kg are specified.

When the “Start Search” button is clicked as an instruction, thissearching condition is sent to the DBS 1 (S65).

Upon receiving the above-noted searching condition data at the DBS 1,the DBMS 10 first extracts as the universe of the row-direction datacells corresponding to the above-noted CATG_NO “16” in the MDT 22 (FIG.15) (S67).

Item names are stored in the row-direction data cells (1) to (11) havingthe CATG_NO of “16” in the DPT 21 (FIG. 10), and verification is made ofthe data cell numbers corresponding to “Age” and “Weight,” which are theabove-noted searching conditions (S68).

In this case, as is clear from FIG. 10, the corresponding data cellnumbers are (2) and (3).

Next, of the row-direction data cells in the above-noted extracteduniverse, the DBMS 10 applies the above-noted searching conditions tothe data stored in column-direction data cells associated with the datacell numbers corresponding to the above-noted verified numbers (2) and(3) (S69).

That is, of the row-direction data cells associated with the categoryname “Dog” (for which the CATG_NO is “16”) in the MDT 22 (FIG. 15), itis only necessary to apply the above-noted searching conditions to thedata in data cells having the verified data cell numbers, which in thiscase means the application of the conditions 2<Y<4 and 15<W<35 to thevalues Y and W which exist in the column direction on condition that theCATG_NO is “16” and the data cell numbers are (2) and (3).

And the DBMS 10 extracts the row-direction data including data thatsatisfies the above-noted searching conditions (S70), and furthergenerates screen data for a list in accordance with the conditionalsearch, with the row-direction setting data associated with the CATG_NO“16” in the DPT 21 (FIG. 10) as a message (S71), writing eachrow-direction data extracted by the search, after which screen data issent to the client 3 (S72 and S73).

As a result, a list in accordance with the conditional search such asshown in FIG. 25 is displayed at the client 3, this list data havingbeen obtained by applying the above-noted searching conditions to thesubstantial contents of the items named “Age” and “Weight” in FIG. 19.

In the list screen of FIG. 25 as well, similar to the case of the listshown in FIG. 19, if an individual underlined title name or “New Window”part is clicked, it is possible to cause a display of the specificcontent.

4. Data Modification (Updating and Deletion) Procedure

At the client 3, there are cases in which it is desired to modify thesubstantial contents registered in the MDT 22 (FIG. 15) of the DBS 1.For example, if the specifications of a registered product change, therearises the necessity to overwrite or delete the substantial contentsassociated with a particular item name.

In such cases, at the DBS 1 of this embodiment, although not shown inthe drawings, a screen is sent for the purpose of registration,modification, and deletion of data such as shown in FIG. 12 to FIG. 14,in response to a request from the client 3 specifying a title name orcode number.

In the case in which the above-noted necessity has occurred, the client3 obtains the noted screen and, after performing a desired correction ordeletion, clicks the “Page Update” button at the bottom of the screen,so as to sent the changed data to the DBS 1.

When this is done, the DBMS 10 at the DBS 1 side sets the registereddata associated with the corresponding title name in the MDT 22 (FIG.15) as data to be updated, and overwrites this data with the changeddata.

In this case, the DBMS 10 permits the updating to be made by verifyingthe relationship of correspondence between the row-direction data cellsof the category name including the title name in the DPT 21, and therow-direction data cells of that category name and the title name in theMDT 22.

In this DBS 1, the above-noted overwriting of registered data is, ofcourse, performed without any effect to other registered data in thesystem and without the need to change the program.

5. Procedure for Modifying an Item Associated with a Category

If a function or an attribute associated with an actual phenomenon orthing belonging to an already-registered category changes, there couldbe a desire from the client 3 to modify the item, making it necessary toaccommodate this at the DBS 1 side.

In the above-noted section 4, because only a change to substantial datastored in the data cells (1), (2), (3) and so on of the MDT 22 (FIG. 15)was done, arbitrary execution was possible at the client 3. In the caseof modifying a category item, however, because this will change the DPT21 (FIG. 10) and could influence the function of the DBS 1, in principlethis is performed by an administrator, using a management personalcomputer 15 at the DBS 1 side.

That is, because there is a correspondence set up by the data cellnumber between data cells associated with each item name on the DPT 21(FIG. 10) side and data cells into which each substantial contents isstored on the MDT 22 (FIG. 15) side, if this correspondence relationshipis lost, erroneous input, storage, searching, and output will occur withregard to stored information of the category in which the item wasmodified.

Forms of modifications to an item that can be envisioned are a.“modifying of an item name”, b. “adding of an item”, and c. “deleting ofan item”.

a. With regard to “modification of an item name,” because this is merelya change to the item name, which does not affect the system functioning,in the case in which a plurality of clients 3 register data having onecategory name, although there is a need to check whether or not a skewoccurs within the substantial contents associated with the item name atthe MDT 22 (FIG. 15), if no problem is discovered, this can bepermitted.

In the case in which a skew occurs, the solution is often one of “addingof an item,” as described below is section (b).

But, in the case in which a particular client 3 only registers data intoone category name, there is no obstacle for the permission of themodifying of the item name.

b. With regard to “adding of an item,” an added item name with regard toa category name of the DPT 21 (FIG. 10) and the item data attributes andthe like thereof are set and registered, and the substantial contentsonly has to be registered in the MDT 22 (FIG. 15) by using the settingdata of the DPT 21 (FIG. 10) from the newly added registeredinformation.

In this case, although the substantial contents that had been registeredbefore do not exist for the added item, with regard to results of asearch it is sufficient to make a blank display for the regioncorresponding to the substantial contents of that item name.

c. With regard to “deleting of an item,” the item name and associateditem data attributes and the like of the DPT 21 (FIG. 10) are deleted,along with deletion of the substantial contents of a correspondingcolumn of the MDT 22 (FIG. 15).

In this case, if a particular client 3 only registers data into onecategory name, and that client 3 desires it, it is possible to permitthis. If this is not the case, however, it is necessary to obtain theapproval of other clients 3.

Seen from a client 3, the problem is whether or not substantial contentsare output in response to a search, and so on, so that if deletion isperformed of an item not in the DPT 21 (FIG. 10), but rather of thesubstantial contents associated with the item in the MDT 22 (FIG. 15),the substantially same effect is provided for this desire. Although theitem name will remain in the search results and the like, thesubstantial contents thereof will be displayed blank.

As described above, in a database system DBS 1 of this embodiment, it ispossible to flexibly accommodate changes in an item associated with acategory, and even if a change occurs, the change does not influencedata of other categories, and what is more important is that there isthe great advantage of not having to re-edit the program.

INDUSTRIAL APPLICABILITY

As described above, the present invention can be applied to a databasesystem which comprehensively handles any category or phenomena orthings, and has only a very simple table structure, and has therevolutionary feature of being able to use a general-purpose program foreach function, without regard to the registered data contents.

By virtue of the above, when compared to RDB, OODB, and ORDB of thepast, the present invention achieves a simplification of the tablestructure, a great reduction in the size of the program, and a greatreduction in the cost of implementing the database system. Additionally,it is possible to accommodate change in data or an item with extremeflexibility, eliminating the need to change the program, which, in thedatabase system of the past, required a great deal of time and labor.Hence, this also provides great reduction in the cost of the systemoperation and maintenance.

In particular, used as an online DBS, the present invention is extremelyeffective in implementing a system in which data is registered andsearched for by a client via a network.

1. A database system, while managing-category na-mes, which are abstractcontents of registered information (phenomena or things), and thehierarchy thereof by a data dictionary file, registers category name,individual title name, and substantial contents of each piece ofinformation being registered, wherein said system comprising a firsttable and a second table, which are formed by data cells, and in saidfirst table, category identification information given by said datadictionary file is stored in a data cell of a specific column, and namesof items which represent an attribute and/or a function associated withthe category and attributes of data representing the substantialcontents associated with said items (hereinafter referred to as itemdata attributes) are stored in other cells, each belonging to a row inwhich said category identification information is stored, and in saidsecond table, category identification information and a title name arestored in each cell of two specific columns, the substantial contentsassociated with each item name being stored in other data cells, eachbelonging to a row in which category identification information andtitle names are stored, in the same sequence with regard to item namesas the row-direction sequence of data cells into which are stored itemnames and item data attributes in said first table, and each method forinput, storage, searching, and output of data associated with registeredinformation being generated based on data stored in said first table. 2.A database system according to claim 1, comprising: a first storagemeans into which is stored a first registration screen onto which aredisposed an input field for a category name, which is an abstractconcept of handled information, an input field for each item namerepresenting an attribute and/or a function associated with saidcategory, and an input field for defining item data attributes for eachitem associated with said item names; a first display means for readingout and displaying a first registration screen of said first storagemeans; a first table formed by data cells; a first registration means,which uses data cells of a specific column of said first table as astorage area for category identification information given by said datadictionary file and assigns each data cell of other column as a storagearea for item names and item data attributes, and which, based on inputinto said each input field of said first registration screen, registerssaid category identification information, item names, and item dataattributes in units of rows; a second display means for displaying asecond registration screen, which generates a display method based onrow-direction data associated with said category name of said firsttable, and on which is disposed an input field for a title nameassociated with said registered information, a display field for displayof each item name, and an input field for substantial contentsassociated with each item name; a second table formed by data cells; asecond registration means, which uses each data cell of two specificcolumns of said second table as storage areas for categoryidentification information and title names and assigns each data cell ofother columns as a storage area for substantial contents associated withsaid item names, and which, based on input into each input field in saidsecond registration screen, stores category identification information,title name, and substantial contents associated with each item name inunits of rows, this storage being performed so that row-directionsequence of said each data cell into which said substantial contentsassociated with each item name is stored is the same with regard to itemnames as a row-direction sequence of each data cell in said first table,into which are stored item names and item data attributes; a data outputmeans, which, in a case in which an inquiry is made with variousconditions, based on data registered in said first table associated fromsaid data dictionary file, generates an access method for said secondtable and an output method for registered data obtained by that accessmethod, these methods causing output of registered data in response tosaid inquiry.
 3. A database system according to either claim 1 or claim2, wherein a data type is provided as a defining item for said item dataattributes.
 4. A database system according to any one of claim 1, claim2, and claim 3, wherein a data type and data size are provided asdefining items for said item data attributes.
 5. A database systemaccording to any one of claim 1, claim 2, claim 3, and claim 4, whereina data type, a data size, a unit, and a range specification are providedas defining items for said item data attributes.
 6. A database systemaccording to any one of claim 3, claim 4, and claim 5, wherein aselection menu is provided for selection of character type, value type,date type, image type, or audio type as the data type defining said itemdata attributes.
 7. A database system according to any one of claim 3,claim 4, claim 5, and claim 6, wherein a selection menu is provided thatindicates data obtained by a link to another application and/or a linkto another system as a data type defining said item data attributes. 8.A database system according to any one of claim 2, claim 3, claim 4,claim 5, claim 6, and claim 7, wherein when said second registrationmeans, based on input into said input fields of said second registrationscreen, stores substantial contents associated with each item name intoeach data cell of said second table, if the amount of data thereof islarge, said data is stored into a second storage means having a largecapacity, and only the corresponding address in said second storagemeans into which is stored said data is stored into the correspondingdata cell of said second table.
 9. A database system according to anyone of claim 2, claim 3, claim 4, claim 5, claim 6, claim 7, and claim8, wherein said first storage means stores said first registrationscreen-provided with input fields in display sequence corresponding toinput fields for input of each item name, said first registration meansadds each input display sequence input to said item data attributescorresponding to each item name, storing this in data cells of saidfirst table, and wherein said data output means generates an outputmethod which is setting the display sequence for the substantialcontents associated with each item name based on said display sequenceassociated with said input.
 10. A database system according to any oneof claim 2, claim 3, claim 4, claim 5, claim 6, claim 7, claim 8, andclaim 9, wherein in response to a connection request sent via a networkfrom a client, a circuit connection is made with said client, and inresponse to a client-side registration request, said first registrationscreen generated by said first display means is provided to theclient-side, and based on transmission of input data to said firstregistration screen by the client-side, the input data is registeredinto said first table, and based on said registered data associated withsaid category identification information of said first table, saidsecond registration screen generated by said second display means isprovided to the client-side, and based on transmission of input data tosaid second registration screen by the client-side, the input data isregistered into said second table, and, based on an inquiry from aclient-side, various inquiry screens prepared beforehand are provided tothe client-side, and in response to inquiry condition, said data outputmeans provide the registered data of said second table to theclient-side.